r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

Hm, does the lint itself have lots of false positives then? Most projects deny all warnings in CI, so whether it's part of unused or not doesn't seem like it would matter that much?

@Mark-Simulacrum
#![deny(warnings)] doesn't deny allow-by-default lints, only warn-by-default ones.
For example, https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=9bd06857be49d26a979aece1b997e71b

r=me if you wish. Can we create a tracking ticket to make sure we eventually figure out how to make cargo not trigger this unecessarily?

@bors r=estebank rollup

Can we create a tracking ticket to make sure we eventually figure out how to make cargo not trigger this unecessarily?

I'm not sure whether it's a part of rust-lang/cargo#7916 or some other related existing issue.
cc @ehuss

📌 Commit 1eef0c3 has been approved by estebank

Oh I think I missed that it's already allow-by-default then, thanks!

I don't think it is possible for Cargo to support this lint as-is for normal builds (without the false positives).

There are a few alternatives:

• Provide cargo-target-specific dependencies (such as Allow specifying dependencies for individual artifacts rfcs#2887). Unfortunately this would require the user to very carefully separate the dependency declarations, and I suspect that will be awkward and difficult in some situations.
• Use cargo-udeps which I think is the only way to solve this right now for Cargo projects.

As I mentioned in the original PR, I feel like this lint is only useful for non-cargo build systems, or adventurous people who want to wade through the false positives. I would recommend cargo-udeps otherwise. It might be possible for cargo-udeps to use this lint as an alternative to its other approaches (it has multiple backends).

One workflow that I might imagine where we could reduce the false-positives is to tell Cargo in some JSON-y format about the diagnostics, but not actually emit them by default. Then Cargo would aggregate them and be able to say "this dependency is not used by any target" -- in particular, to detect cases where e.g. you stopped using a dependency entirely.

I agree that this happens somewhat rarely so maybe is not the most important thing to do, though.

@Mark-Simulacrum see discussion in #57274. You can bikeshed a lot about the design whether to make rustc emit the used dependencies or the unused ones, and which format to use (modifying the existing stdout json format, storing json to disk, stabilizing build-dep-depinfo and using .dep files, etc), but:

• any form of the lint that's not full of false positives needs coordination at the Cargo level.

• The rustc lint of Warn about unused crate deps #72342 is useful but for build.rs and non-cargo users (like the PR author) and people for whom it's easier to sift through the false positives than using cargo-udeps.

Maybe I should make a table about which cargo subcommand has enough data to check which dependency section in Cargo.toml.